Modern packet-switched networks accommodate a greater number of users and larger amount of traffic than ever before. Unfortunately, the services desired by users now require a much greater amount of bandwidth, while demanding near real-time service in many cases. Consider, for example, a typical user's experience with a mobile phone. While, several years ago, many users were content with voice-only service, many mobile phones now double as personal computers, providing access to streaming video, peer-to-peer applications, and other high bandwidth applications. Furthermore, non-mobile networks have also experienced a significant increase in traffic, as Voice Over Internet Protocol (VoIP), IP Television (IPTV), and similar services have gradually increased in popularity.
Service providers have struggled to keep pace with the ever-increasing bandwidth requirements. Given the significant expenses associated with adding additional equipment, service providers are reluctant to address this problem by simply increasing the capacity of the network. Instead, many service providers desire to decrease costs and simultaneously improve the user's quality of experience by optimizing the efficiency of data transfer over the network.
One such optimization relates to compression of headers associated with packets transferred over the network. In bandwidth-sensitive portions of the network, many service providers employ a header compression algorithm to decrease the amount of data sent over the network. More specifically, during an initialization phase, a node known as a compressor sends a full header including a context identifier, which identifies the flow associated with the packet. A node known as a decompressor receives the full header and stores the associated context identifier. Subsequently, the compressor may send a “compressed” version of the header, which includes the context identifier, but omits much of the information included in the full header. Because the decompressor maintains a record of the context identifier and associated header information, the decompressor may reconstruct the full header using the information contained in the compressed version.
Given the differences in the fields contained in packets of different protocols, header compression algorithms must identify each packet and deal with the packet depending on its protocol, as a full header may include different fields. For example, the full header of some non-Transmission Control Protocol (TCP) packets, such as User Datagram Protocol (UDP) packets, includes two usable packet length fields, such that the first packet sent by the compressor may include a two-byte context ID. In contrast, the full header of other non-TCP packets, such as IP-only packets, may only include one packet length field, such that the first packet sent by the compressor may include only a one-byte context ID. Thus, the number of context IDs available for use with an IP-only packet may be only 256 (i.e. the values from 0 to 255).
Current header compression algorithms implemented at the compressor fail to effectively consider these differences when assigning context identifiers. More specifically, current header compression algorithms treat all non-TCP packets the same, such that the compressor may assign every possible one-byte context ID to a number of flows, including UDP flows. In this situation, after all one-byte values have been assigned, the compressor will be unable to establish a compression context for an IP-only flow. As a result, the headers for the IP-only flow will not be compressed, such that a significant amount of bandwidth will be wasted.
For the foregoing reasons and for further reasons that will be apparent to those of skill in the art upon reading and understanding this specification, there is a need for packet header compression that effectively assigns compression context identifiers such that a maximal number of flows may be compressed, while also minimizing memory requirements of the compressor and decompressor.